home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.20030409-20031118 / 000255_fdc@sesame.cc.columbia.edu_Thu Sep 4 10:16:18 EDT 2003.msg < prev    next >
Text File  |  2020-01-01  |  3KB  |  79 lines

  1. Article: 14495 of comp.protocols.kermit.misc
  2. Path: newsmaster.cc.columbia.edu!news-not-for-mail
  3. From: fdc@sesame.cc.columbia.edu (Frank da Cruz)
  4. Newsgroups: comp.protocols.kermit.misc
  5. Subject: Re: missing bytes...
  6. Date: 4 Sep 2003 10:16:10 -0400
  7. Organization: Columbia University
  8. Lines: 62
  9. Message-ID: <bj7hfa$1ho$1@sesame.cc.columbia.edu>
  10. References: <cf6cc183.0309031713.73a00933@posting.google.com>
  11. NNTP-Posting-Host: sesame.cc.columbia.edu
  12. X-Trace: newsmaster.cc.columbia.edu 1062684971 4299 128.59.59.56 (4 Sep 2003 14:16:11 GMT)
  13. X-Complaints-To: postmaster@columbia.edu
  14. NNTP-Posting-Date: 4 Sep 2003 14:16:11 GMT
  15. Xref: newsmaster.cc.columbia.edu comp.protocols.kermit.misc:14495
  16.  
  17. In article <cf6cc183.0309031713.73a00933@posting.google.com>,
  18. icurmt <icurmtdude@yahoo.com> wrote:
  19. : After no luck with this issue, I thought of posting it here.. Heres
  20. : what I am trying to do..
  21. : I am sending out commands out of a file through serial port to my
  22. : application which returns me the response accordingly in return..
  23. : <code snippet...> 
  24. : ..
  25. : ...
  26. : transmit /binary /noecho /nowait <commandsfile>
  27. : input 1 -1
  28. : .output := \fhexify(\v(input))
  29. : echo \m(output)
  30. : ...
  31. : fopen /write \%c <outputfile>
  32. : ..
  33. : fwrite /line \%c \m(output)
  34. : ..
  35. : fclose \%c
  36. : </end>
  37. : The script works fine. The response as under is outputted to the
  38. : 'outputfile'. Now when I echo the response I get
  39. : 16 06 14 34 47 12 01 87 
  40. : instead of 
  41. : 16 06 14 34 47 12 00 01 87 00 00 00
  42. : Note the difference after the 6th byte. The 7th and 8th byte which is
  43. : 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
  44. : all. However I have had success getting bytes in the order such as
  45. : below and echoing this command works fine.
  46. : 16 06 14 34 46 11 00 00 BB 10 00 00 
  47. C-Kermit and K95 written in C, in which strings are NUL-terminated.
  48. Thus it is virtually impossible for it to deal with strings that contain
  49. NUL characters -- we would not be able to use C library calls or Unix
  50. system services, all of which require strings to be in this format.
  51.  
  52. This applies also the INPUT buffer.  \v(input) is a string, hence by
  53. definition NUL-terminated.  Realizing that it is common to receive NUL
  54. characters on a communication connection as padding and/or part of the
  55. Telnet NVT data stream, the INPUT command discards NULs so the \v(input)
  56. value will not be truncated the first time a NUL arrives.
  57.  
  58. The only way to deal with NUL characters is on a per-character basis.
  59. If you want to read a series of characters from the connection that can
  60. include NULs, you have to do it using INPUT with no target text. Example:
  61.  
  62.   while (some condition) {
  63.       input 1
  64.       if fail (do something)
  65.       fwrite /char \%c \v(inchar)
  66.   }
  67.  
  68. This works because when \v(inchar) is NUL, that's equivalent to FWRITE /CHAR
  69. having no text argument at all, in which case it writes a NUL character.
  70.  
  71. - Frank
  72.